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Executive  Summary 


The  Problem :  To  Protect  Soldiers  and  Civilians  from  Airborne -released  Hazards. 

This  report  documents  the  fiscal  year  2011  (FY1 1)  advancement  of  the  U.S.  Anny  Research 
Laboratory  (ARL)  Local-Rapid  Evaluation  of  Atmospheric  Conditions  (L-REAC™)*  System 
decision  aid  technology,  from  “Prototype”  to  “Operational  System.”  To  better  understand  the 
tenn  “operational,”  consider  the  following  scenario  and  consequential  decisions: 

Truck  tires  squeal  loudly  outside  your  office  window.  The  sound  of  thick  metal  submitting  to  the 
immobility  of  a  multi-story  concrete  building  turns  your  eyes  to  the  window.  A  strange,  un¬ 
friendly  odor  begins  to  fill  the  air.  ...and  the  emergency  “first  response  ”  decisions  begin. 

In  any  emergency,  there  will  be  many  levels  of  decisions.  These  decisions  begin  with  the 
building  occupants  who  must  decide  whether  to  shelter-in-place  (SIP),  evacuate  or  take  the  time 
to  call  for  help.  Building  custodians  and  supervisors  must  decide  how  to  best  advise  the  building 
occupants  and  secure  help.  The  Help  Dispatch  (911  operators)  must  decide  how  to  advise 
residents  and  detennine  which  response  units  to  dispatch  (security,  safety  and  property 
preservation)  and  suggest  how  these  units  might  safely  approach  the  hazardous  incident.  Each 
emergency  unit  dispatched  must  detennine  the  critical  safety  requirements  with  regard  to  their 
approach,  their  attire,  and  their  assigned  tasks.  And  then  there  are  the  Incident  Commanders  (at 
a  command  center  and/or  in  the  field)  who  need  to  conceptualize  the  extent  of  the  incident' 's 
impact  and  advice  field  units  accordingly.  All  these  critical  decisions,  as  well  as  other  cascaded 
choices  will  continue  until  the  area  of  interest  (AOI)  is  once  again  declared  safe  for  public  use. 

What  common  use  tool  is  there  that  will  aid  each  of  the  decision  makers  listed  above? 

ARL  has  been  developing  a  decision  aid  beneficial  to  each  of  the  above  decision  makers.  This 
technology  is  a  product  of  three  detailed  ARL  urban  field  studies  that  characterized  the  airflow 
and  stability  around  a  single  urban  building.  Three  disaster  response  exercises  were  included  in 
the  last  urban  field  study.  From  these  experiences,  the  need  to  bring  timely  and  relevant 
atmospheric  conditions  to  emergency  response  decision  makers,  in  a  user-friendly  fonnat,  came 
into  focus.  ARL  answered  this  requirement  by  developing  the  L-REAC™  System.  The  ultimate 
goal  for  this  tool  is  to  improve  military  and  civilian  situational  awareness  of  the  natural 
environment  and  to  better  respond  to  potentially  life-threatening  airborne  hazard  events. 

The  L-REAC™  System  is  composed  of  five  foundational  hardware/software  subsystems  (or 
Modules)  linked  by  specialized  networks.  These  subsystems  consist  of:  (1)  a  Sensor  Module, 

(2)  a  Model  Module,  (3)  an  End  User  Display  (EUD)  Module,  (4)  a  data  Quality  Control  (QC) 
Module,  (5)  and  an  Archive  Module.  The  Sensor  Module  was  designed  to  provide  timely 
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(current)  and  relevant  atmospheric  data  from  a  single  and/or  an  ensemble  of  meteorological 
sensors.  The  Model  Module  interprets  these  data  by  generating  an  air  flow  field  over  a  given 
AOI  within  2-10  min  (depending  on  the  domain  size)  of  receiving  the  atmospheric  data.  The 
EUD  continually  displays  the  current  wind  field  to  authorized  end  users,  for  a  given  AOI.  If  an 
airborne  hazard  is  defined,  the  user  enters  this  information;  the  EUD  Module-plume  model 
evaluates  the  current  atmospheric  conditions  and  produces  a  mapped  toxic  plume.  The  EUD 
Module-display  then  collates  this  mapped  hazardous  image  to  the  perpetual  wind  field  updates. 
These  results  are  distributed  to  authorized  users  over  established  communication  networks. 

These  networks  ensure  a  timely  information  flow  (on  the  order  of  minutes)  from  the  atmospheric 
sensors  and  models,  to  the  decision-maker  EUD  displays. 

In  this  third  volume  documenting  the  development  of  the  ARL  L-REAC™  System,  we  briefly 
describe  the  research  that  prompted  the  L-REAC™  System  concept,  and  the  two  predecessor 
units  (Proof  of  Concept  and  Prototype)  leading  to  the  current  Operational  L-REAC™  System. 

The  Operational  L-REAC™  System  is  presented  by  Modules.  The  discussion  section  of  this 
report  includes  some  of  the  future  development  being  pursued.  One  of  the  highlights  to  this 
year"s  development  effort  was  having  the  L-REAC™  System  participate  in  real  world  events  and 
Force  Protection  Exercises.  Another  was  having  the  system  evaluated  in  detail,  by  professional 
first  responders.  A  preliminary  summary  capturing  a  sample  of  the  very  positive  feedback  given 
by  these  emergency  first  responders  precedes  the  final  comments.  This  report  concludes  the 
Department  of  Defense  Technology  Readiness  Level  five  (out  of  nine)  journey. 
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1.  Background 


This  report  documents  the  fiscal  year  2011  (FY1 1)  advancement  of  the  U.S.  Army  Research 
Laboratory  (ARL)  Local-Rapid  Evaluation  of  Atmospheric  Conditions  (L-REAC™)*  System 
decision  aid  technology,  from  “Prototype”  to  “Operational.”  To  better  understand  the  term 
“operational,”  we  present  a  scenario  that  captures  both  the  problem  being  addressed  by  this 
technology  and  the  niche  in  which  the  Operational  L-REAC™  System  fills. 

The  Problem :  To  Protect  Soldiers  and  Civilians  from  Airborne -released  Hazards. 

Truck  tires  squeal  loudly  outside  your  office  window.  The  sound  of  thick  metal  submitting  to  the 
immobility  of  a  multi-story  concrete  building  turns  your  eyes  to  the  window.  A  strange,  un¬ 
friendly  odor  begins  to  fill  the  air.  ...and  the  emergency  “first  response”  decisions  begin. 

In  any  emergency,  there  will  be  many  levels  of  decisions.  For  the  given  incident,  an  airborne 
hazard  leaking  from  an  impacted  chemical  tanker  vehicle-here  is  a  typical  sequence  of  decisions 
put  in  chronological  order: 

1 .  Building  occupants  of  the  impacted  and  neighboring  buildings  must  decide  whether  to  SIP, 
evacuate  or  take  the  time  to  call  for  help. 

2.  Building  custodians  and  supervisors  must  decide  how  to  best  advise  building  occupants  and 
secure  help. 

3.  The  Help  Dispatch  (911  operators)  must  decide  how  to  advise  residents:  SIP  or  evacuate. 
They  also  determine  which  response  units  to  dispatch  (security,  safety  and  property 
preservation)  and  suggest  how  these  units  might  safely  approach  the  hazardous  incident. 

4.  Each  emergency  unit  dispatched  must  determine  the  critical  safety  requirements  with 
regard  to  their  approach  and  their  assigned  tasks.  For  example: 

4. 1  Airborne  hazards  may  require  special  protective  gear  for  participants,  in  order  to 
protect  the  human  body. 

4.2  Security:  Police  assigned  to  security  and  traffic  control  need  to  know  the  hazards  of 
their  assigned  duty  site  and  task,  which  may  be  securing  a  building,  directing  traffic, 
etc. 

4.3  Safety:  Medical  units  need  to  establish  Hazard  Control  Zones  for  addressing  the 
incident,  for  detoxifying  personnel/equipment,  and  for  providing  a  safe  environment  in 
which  their  multiple  support  activities  can  function.  They  also  need  to  triage/prioritize 
rescue  locations  of  victims  by  the  vulnerabilities  to  the  victims  and  to  themselves. 

* 
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Fire  crews  need  to  select  appropriate  protection  attire  for  entering  any  structure 
involved  in  an  airborne  hazard  incident. 

4.4  Property:  Fire  units  need  to  address  structural  hazards  involved  in  the  incident.  (Often 
the  safety  and  property  functions  run  in  parallel.) 

5.  Incident  Commanders  (at  a  command  center  and/or  in  the  field)  need  to  conceptualize  the 
extent  of  the  incident' 's  impact  and  advise  field  units  accordingly. 

All  these  critical  decisions,  as  well  as  other  cascaded  choices,  will  continue  until  the  area  of 
interest  (AOI)  is  once  again  declared  safe  for  public  use. 

How  can  these  decision  makers  make  informed  and  potentially  life-saving  decisions?  ARL  has 
been  developing  a  decision  aid  that  provides  timely  and  relevant  atmospheric  infonnation  to 
civilian  and  military  emergency  first  responders.  This  decision  aid  is  called  the  L-REAC™ 
System.  The  research  that  prompted  the  creation  of  L-REAC™  System  is  described  next, 
followed  by  a  description  of  the  system. 

1.1  Research  Leads  to  a  New  Technology 

The  foundational  research  for  the  L-REAC™  System  Project  began  in  the  early  2000s,  when 
ARL  conducted  three  progressively  more  complex  urban  field  studies.  The  first  study,  called 
White  Sands  Missile  Range  (WSMR)  2003  Urban  Study  ( W03 US),  studied  airflow  and  stability 
around  a  single  urban  building.  This  study  sought  to  verify  the  1994  Environmental  Protection 
Agency  (EPA)/National  Oceanic  and  Atmospheric  Administration  (NOAA)  wind  tunnel  results 
by  sampling  atmospheric  data  at  strategic  locations  around  a  rectangular  office  building.  Seven 
airflow  features  were  identified  for  verification.  Figure  1  displays  six  of  the  seven  features: 
fetch  flow,  velocity  acceleration,  velocity  deficit,  cavity  flow,  leeside  corner  eddies/vortices  and 
the  re-attachment  zone.  The  seventh  feature  not  diagramed  was  a  “canyon  flow,”  an  accelerated 
flow  that  occurs  between  two  parallel  buildings.  Based  on  the  successful  W03US  results,  two 
subsequent  urban  studies  were  executed  around  the  same  urban  environment,  each  with  an 
increased  density  of  dynamic  and  thennodynamic  measurements.  These  studies  were  called 
WSMR  2005  Urban  Study  (W05US)  and  WSMR  2007  Urban  Study  (W07US),  respectively.  ARL 
technical  reports  documenting  these  studies  and  their  findings  include:  Vaucher,  2006;  Vaucher 
et  ah,  2008  ( Volumes  DP-1,  DP-2,  DP-3;  2007);  Vaucher,  2007  (Volume  AS-1 ;  2007);  Vaucher, 
2008  (Volume  AS-2;  2007);  Vaucher,  2011  (ARL-TR-5706:  W07US,  Data  Analysis,  Volume  DA- 
1).  During  W07US,  simulated  disaster  response  drills  were  run  concurrently  with  the  data 
acquisition.  From  this  experience,  the  concept  for  a  near  real-time  atmospheric  evaluation 
system  was  identified. 
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(Snyder  and  Lawson.  Jr ,  1994) 


Figure  1.  EPA/NOAA  wind  tunnel  results  show  the  airflow  pattern  around  a  single  building. 

Streamline  flow  is  from  left  to  right.  The  “canyon  flow”  is  not  shown.  (Snyder  and 
Lawson,  Jr.,  1994). 

In  2009,  the  near  real-time  atmospheric  evaluation  system  concept  was  labeled  the  L-REAC™ 
System  and  was  manifested  in  a  tangible,  Linux-Windows  dual  operating  system  (OS)  Proof  of 
Concept  (PoC).  The  L-REAC™  System  PoC  included  three  core  modules  linked  by  specialized 
networks.  These  modules  consisted  of  a  Sensor  Module,  a  Model  Module,  and  an  End-User- 
Display  (EUD)  Module  (see  figure  2).  The  details  for  each  module  will  be  presented  in  later 
sections.  The  L-REAC™  System  PoC  was  documented  in  the  Volume  1  (Vaucher  et  ah,  2009). 


Local  -  Rapid  Evaluation  of  Atmospheric  Conditions  System 


Figure  2.  The  L-REAC™  System  PoC  included  sensors  continually  acquiring  data  from  a  representative 
location  in  the  AOI,  a  Wind  Field  Model  continually  interpreting  the  wind  flow  conditions 
based  on  the  sensor  input,  a  Plume  Model  assessing  the  airborne  hazard  scenario,  and  an  EUD 
communicating  both  the  near  real-time  wind  flow  and  hazard  assessments. 

In  2010,  a  single  Windows  OS  L-REAC™  System  “Prototype”  was  constructed.  Within  this 
“Prototype”,  the  three  core  modules  were  significantly  enhanced,  and  two  system  features  within 
the  earlier  design  were  re-designated  as  full  modules.  The  two  features  were  labeled  the  Quality 
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Control  (QC)  Module  and  Archive  Module.  Additional  details  for  each  of  these  Modules  will  be 
expounded  on  in  a  later  section.  The  “Prototype”  System  was  documented  in  the  Volume  2 
(Vaucher  et  ah,  2010). 

In  FY 1 1 ,  improvements  to  each  system  module  continued,  and  the  end  product  was  called  the 

TM  .  .  TM 

Operational  L-REAC  System.  One  of  the  primary  goals  for  the  Operational  L-REAC  System 
was  to  bring  the  operational  system  into  a  field  environment,  where  professional  emergency  first 
responders  would  provide  a  practical  end  user"s  evaluation.  A  sample  of  the  results  from  these 
evaluations  is  included  within  this  report. 

TM 

1.2  The  Basic  L-REAC  System  Design 

The  L-REAC™  System  is  an  automated,  24/7,  emergency  response  decision  aid  for  airborne 
toxic  release  incidents.  The  current  L-REAC™  System  design  is  composed  of  five  core  modules, 
three  of  which  comprise  the  foundational  hardware/software  subsystems  linked  by  specialized 
networks.  These  subsystems  include  a  Sensor  Module,  a  Model  Module,  and  a  EUD  Module. 
The  Sensor  Module  is  designed  to  provide  timely  (real-time)  and  relevant  atmospheric  data  from 
a  single  and/or  an  ensemble  of  meteorological  sensors.  The  Model  Module  interprets  the 
contemporary  data  by  generating  a  local  wind  field  over  the  AOI.  This  wind  field  is 
continuously  updated  by  the  Sensor  Module  data  feed  and  the  output  is  displayed  by  the  EUD 
Module.  When  an  airborne  hazard  occurs,  a  trained  operator  keys  in  the  hazard  specifications 
(for  example,  hazard  type,  amount,  release  method,  and  so  forth)  to  a  quick  processing, 
emergency  response  plume  model,  which  is  also  part  of  the  EUD  Module.  This  third  module 
automatically  assimilates  and  synchronizes  the  wind  and  plume  model  outputs  into  both 
building-  and  regional-scaled  images  for  the  end  user  to  utilize  for  assessing  safe/hazard  zone 
decisions.  The  EUD  output  is  distributed  to  end  users  over  their  established  networks.  Updates 
to  the  wind  field  (and  plume)  outputs  are  automatically  transmitted  to  the  end  users  after  each 
wind  field  model  run  is  completed.  A  System-specific  network  ensures  a  timely  infonnation 
flow  (on  the  order  of  minutes  for  building  scales  and  8-10  min  for  regional  scales)  from  the 
atmospheric  sensors  and  models,  to  the  decision-maker  EUD  displays.  An  “Instantaneous  Save” 
option  allows  the  system  operator  to  zoom  in/out  on  an  end-user-specified  area  and  immediately 
transmit  those  results,  between  the  automated  cycles. 

Since  model  output  is  highly  dependent  on  the  quality  of  data  ingested,  a  data  QC  Module  allows 
the  user  to  instantly  evaluate  the  status  of  all  the  L-REAC™  System  sensors.  An  Archive  Module 
saves  the  ingested  L-REAC™  data,  and  when  the  user  selects  the  option,  saves  all  incident  EUD 
imagery  as  well.  These  archive  files  can  be  used  for  incident  reviews  and  Post-Event  data 
analyses. 


4 


1.3  Defining  an  Operational  System 

The  operational  environment  for  the  L-REAC™  System  technology  was  described  in  an  earlier 
section.  We  address  the  concept  of  what  an  operational  system  is,  here.  One  definition  of  an 
operational  system  is  a  system  that  is  easy  to  download,  easy  to  set  up,  capable  of  running  in 
most  environments  (geographical  and  computational),  reliable,  and  accurate.  However,  this 
report  is  not  describing  the  usual  operational  system.  We  are  describing  a  system  that  solves 
very  specific  customer  requirements,  on  a  developer-chosen  computer  system,  using  specific 
inputs  and  requiring  specific  knowledge  of  the  geographical  site.  Therefore,  this  system  was 
considered  operational  if  it  could  run  reliably  and  produce  results  that  would  satisfy  the 
requirements  of  our  intended  customers.  Given  these  constraints,  we  believe  the  Operational 
L-REAC™  System  has  been  successfully  accomplished. 

TM 

1.4  The  L-REAC  System  Demonstration  Unit 

To  prove  the  L-REAC™  System  design,  a  demonstration  unit  was  created  and  evolved  into  what 
is  today  the  Operational  L-REAC™  System.  While  the  system  design  was  purposefully 
constructed  around  flexible  modules,  the  demonstration  system  uses  specific  features.  In  this 
section,  we  briefly  re-cap  some  of  the  key  features  of  the  current  demonstration  system. 

The  PoC  showed  that  an  L-REAC™  System  could  be  built  on  a  dual  OS.  However,  the 
Operational  L-REAC™  System  was  built  on  the  simplicity  of  the  Prototype"s  single  OS.  The 
specialized  networks  linking  each  system  element,  ranged  from  Production  and  Standard  internet 
to  a  Demilitarized  Zone  (DMZ)  network.  These  networks  facilitated  the  opportunity  to  ingest 
regional  meteorological  data.  For  the  operational  system,  the  regional  data  were  ingested  from 
the  Surface  Automated  Meteorological  System  (SAMS)  data  network. 

The  dedicated  sensor  suite  sub-components  continue  to  be  based  on  Model  input  requirements 
and  the  anticipated  hard-power  loss  often  associated  with  an  incident.  Consequently,  the 
required  wind  sensor  remained  a  Wind  Monitor  (see  figure  4),  which  was  able  to  display  the 
critical  wind  directions  even  when  power  was  not  supplied  to  the  meteorological  sensor  suite. 
This  choice  ensured  that  the  onsite  victims  would  have  a  visual  reference  for  where  the  ,, upwind" 
safe  zone  was  located.  Data  from  all  sensors  were  acquired  every  1  min  and  archived  for  post¬ 
event  analysis  or  reviews. 

A  pre-compiled  Wind  Model  ( Three-Dimensional  Wind  Field  (3DWF)  Model-Version  1)  was 
initially  run  on  a  Linux  platform  for  the  PoC.  For  the  Prototype,  the  L-REAC™  System  wind 
model  expanded  the  AOI  scale  from  a  building  only  area  to  a  building  and  cantonment  AOI.  For 
the  Model  Module,  this  action  required  replacing  the  original  Linux  3DWF-Version  1  with  a 
Windows  3DWF-Version  2,  as  well  as,  securing  additional  meteorological  data  resources  and  the 
additional  office  building  descriptions  to  support  the  larger  domain  of  high  resolution  wind 
output.  The  Operational  L-REAC™  System  Model  Module  continues  to  run  3DWF -Version  2, 
but  supports  a  third,  larger-scaled  regional  output.  (Wang  et  ah,  2005) 
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The  Plume  Model  selected  for  L-REAC™  System  demonstration  unit  was  a  pre-compiled 
EPA/NOAA  Areal  Locations  of  Hazardous  Atmospheres  (ALOHA)  dispersion  model.  To 
automatically  ingest  data  into  this  model,  ARL  and  EPA/NOAA  created  specialized  software 
( ALOHA  User ’s  Manual,  2007).  Visualization  improvements  at  the  request  of  users  were  added 
to  the  Operational  L-REAC™  System  plume  model. 

The  wind  and  plume  models  generated  output  once  per  minute  on  the  PoC.  With  the  additional 
mesonet  data  ingested  and  consequently  an  Objective  Analysis,  this  time  was  lengthened  to 
1-2  min  for  data  processing.  When  the  cantonment  scale  wind  field  model  was  run,  the  required 
increased,  again.  The  maximum  time  required  for  the  Operational  L-REAC™  Systems  regional 
scale  wind  field  model  run  was  8-10  min. 

Note:  The  L-REAC™  design  is  not  limited  to  the  3DWF  (wind  field)  and  ALOHA  (plume) 
models.  These  were  chosen  to  demonstration  the  feasibility  of  the  L-REAC™  System  concept 
and  to  satisfy  user  requirements.  Section  2  includes  some  of  the  experimental  investigation  into 
alternate  models. 

The  L-REAC™  System  output  included  two  incident  visualization  images.  The  first  EUD 
Module-Display  image  included  a  separate  graphic  for  the  wind  and  plume  outputs.  In  this 
configuration,  the  wind  model  used  a  Grid  Analysis  And  Display  System  (GrADS)  (September, 
2007)  plan  view  of  the  subject  area,  overlaid  with  2.5-m  above  ground  level  (AGL)  wind  vectors, 
wind  streamlines,  and  color  contour  wind  speeds.  The  Plume  Model  output  showed  a  static,  plan 
view  overlaid  with  the  ALOHA  hazard  footprint.  The  model  update  plots  were  shown  side  by 
side  in  an  end-user  display.  This  display  was  automated  using  the  platfonn  independent 
HyperText  Markup  Language  (HTML).  The  final  results  were  displayed  on  the  L-REAC™ 
System  and  remote  tenninals. 

A  second  EUD  Module-Display  output  consisted  of  a  single  image  founded  on  a  Google  Earth 
satellite  map  with  wind  field  and  plume  overlays  written  in  keyhole  markup  language  (kml) 
format.  In  this  fonnat,  the  output  could  easily  be  tilted  to  show  the  flow  over  and  around  the 
mountains,  zoomed  in  until  there  is  only  one  arrow  in  the  scene,  or  zoomed  out  to  show  the 
overall  atmospheric  scenario. 

A  Visual  Basic  Script  (VBScript)  performed  automated  archiving  of  output  files  and  executed 
instant  data  QC  time-series  displays  for  each  variable  of  the  dedicated  L-REAC™  sensor  suite. 

The  total  L-REAC™  System  was  designed  to  function  independent  of  an  operator  and  24/7. 
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2.  Operational  L-REAC™ 


In  this  section,  we  describe  the  advances  made  in  the  construction  of  the  Operational  L-REAC™ 
System.  This  section  begins  with  the  foundational  structure  of  the  computer  platform  and 
networking  challenges,  followed  by  a  description  of  each  module. 


2.1  Computer  System  Administration  and  Networking 

The  first  major  change  from  the  original  PoC  was  a  re-design  of  the  L-REAC™  infrastructure. 
The  Prototype  still  required  both  the  Windows  and  Linux  operating  environments  to  support  the 
wind  and  plume  models,  as  well  as  the  communication  functions.  However,  with  the  change 
from  a  Local  Network  to  a  Production  Network,  the  default  single  computer  platform  became  a 
Windows  Vista  OS.  The  Linux  functions  were  accommodated  through  a  cygwin  software 
package.  Later  in  the  development,  meteorological  data  outside  of  the  Production  Network  had 
to  be  ingested,  which  introduced  Web  transfer  utilities. 


The  Operational  L-REAC™  System  kept  the  Prototype"s  infrastructure  design,  with  the  addition 
of  the  DMZ  Network.  The  primary  function  of  the  DMZ  network  was  to  communicate  with  the 
“outside  world.”  For  simplicity,  the  networking  features  will  be  explained  later,  in  the  context  of 
their  applications.  A  schematic  overview  of  the  Operational  L-REAC™  System  configuration  is 
shown  in  figure  3.  The  System  scripts  used  to  initiate,  automate,  and  terminate  the  L-REAC™ 
System  will  also  be  presented  later,  after  each  module  has  been  described. 
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Figure  3.  Operational  L-REAC™  System  schematic. 
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2.2  Sensor  Module 


The  Operational  L-REAC™  System  Sensor  Module  was  designed  after  the  successful  Prototype- 
Sensor  Module.  That  is,  it  consists  of  a  dedicated  meteorological  resource  attached  to  and 
managed  by  the  L-REAC™  System.  In  support  of  the  larger  AOI  requirements,  the  Sensor 
Module  also  continues  to  ingest  other  mesonet  meteorological  data  resources.  Since  the 
“ownership”  of  these  regional  data  were  not  part  of  the  L-REAC™  System,  their  physical  setup 
and  layout  are  not  included  in  this  report.  The  Operational- Sensor  Module  design  consisted  of 
five  major  areas:  (1)  Sensor  Hardware,  (2)  Sensor  Layout,  (3)  Sensor  Preparation,  (4)  Sensor 
Software,  and  (5)  Sensor  Network  and  Functionality.  The  following  sections  describe  each  area. 

2.2.1  Sensor  Module  Hardware 

The  Operational  Sensor  Module"s  dedicated  meteorological  resources  consisted  of  hardware, 
based  on  the  model  input  requirements.  While  the  models  were  upgraded,  the  sensor 
requirements  remained  the  same.  Therefore,  no  new  sensors  were  added  to  (or  removed  from) 
the  configuration.  Table  1  summarizes  the  variables  and  sensors  utilized  by  the  Operational- 
Sensor  Module.  For  a  more  detailed  description  of  the  Sensor  Module,  see  Volume  1  (Vaucher  et 
al„  2009). 

Table  1.  Sensor  Module  hardware.  For  additional  information  on  the  sensors,  see  Volume  1  (Vaucher  et  at,  2009). 


Variable 

Sensor 

Manufacturer 

Model 

Units 

Pressure 

Barometer 

Vaisala 

PTB-101B 

Millibars 

Temperature 

Thermometer 

107-L 

Celsius 

Temperature/ 
Relative  Humidity 
(RH) 

Thermometer/ 

Hygrometer 

Vaisala 

HMP45AC 

Celsius/Percent 

Wind  Speed  and 
Wind  Direction 

Anemometer 
(Wind  Monitor) 

RM  Young 

05103 

Meter/Second, 

and 

Degrees 

Solar  Radiation 

Pyranometer 

Kipp/Zonen 

CM3 

Watts/Meter 

Micrologger 

ALL 

Campbell  Scientific 

CR23X 

Weather-Resistant 

Enclosure 

ALL 

Campbell  Scientific 

ENC  16/18 

Note:  The  L-REAC™  System  used  calibrated  hardware  components  from  previous  field  tests.  This  resource  insured  that  the 
components  had  a  proven  durability  and  that  system  development  costs  would  remain  very  low. 

2.2.2  Sensor  Module  Layout 

The  original  L-REAC™  System  Sensor  Module  hardware  configuration  was  able  to  survive  the 
harsh  desert  environment  for  over  a  year,  even  withstanding  wind  gusts  in  excess  of  100  miles 
per  hour  (mph).  Therefore,  the  Operational-Sensor  Module  began  by  adopting  the  Prototype 
sensor  configuration,  to  include  the  ability  to  ingest  the  sensor  data  via  an  RS-232  connection. 
The  physical  layout  of  the  “Operational”  instruments  on  the  6-m  tripod  is  tabulated  in  table  2.  A 
schematic  and  photo  of  the  tripod  and  sensor  placement  is  shown  in  figure  4. 
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Table  2.  Operational  L-REAC™  System  Prototype  sensor  tripod  layout. 


Sensor  Variable 

Height 

(Above  Roof  Level) 

Wind  Speed/Direction 

6  m 

T  emperature-Upper 

5.7  m 

T  emperature-Lower 

0.7  m 

RH/T  emperature 

2  m 

Solar  Radiation 

2  m 

Pressure 

0.25  m 

While  designing  the  Operational-Sensor  Module,  we  considered  feeding  the  L-REAC™-Sensor 
Module  data  into  an  alternate  computer  system.  This  second  system  would  imitate  a  dual 
processing  function,  which  would  later  prove  or  disprove  the  feasibility  of  supporting  a  second 
tier  of  slower  application  models  being  run  on  a  dual  processor  L-REAC™  System  design.  Three 
options  were  considered: 

1.  First,  with  the  current  L-REAC™  System  still  operational,  a  quest  to  simultaneously  feed 
the  data  from  the  single  tripod  to  two  competing  L-REAC™  Systems  was  undertaken.  This 
option  proved  to  be  very  difficult.  We  tried  making  a  data  tap  cable  of  our  own  supplies, 
with  only  partial  success.  We  then  tried  two  different  commercially  bought  data  taps,  one 
did  not  work  at  all  and  the  other  worked  once  for  a  couple  of  hours  and  then  never  again. 
We  abandoned  this  design. 

2.  The  second  option  was  to  use  an  independent  tripod  of  meteorological  sensors  placed  near 
the  current  L-REAC™  roof  tripod.  The  placement  of  this  second  sensor  suite  would  be 
non-trivial,  since  there  was  a  heating  vent  to  be  considered,  and  due  to  limited  real-estate, 
there  was  the  possibility  of  introducing  a  systematic  data  error  by  the  two  tripods 
interfering  with  (shadowing)  each  other.  We  did  not  use  this  design  because  of  the  high 
potential  for  non-representative  data  measurements. 

3.  The  third  option  required  permission  to  send  a  copy  of  the  data  collected  on  the  current 
L-REAC™  System  to  an  alternate  computer  via  an  internal  private  network.  When  we 
asked  for  pennission,  our  Infonnation  Technology  colleagues  suggested  we  reverse  the 
data  flow,  sending  it  to  the  alternate  computer  first,  and  then  the  current  L-REAC™  System. 
Because  the  alternate  computer  used  a  Linux  OS,  it  was  considered  easier  to  take  the 
incoming  data  from  there  and  send  a  copy  to  the  current  L-REAC™  System  via  the  private 
network.  However,  resolving  the  competition  for  resources  of  this  process  with  the  other 
active  L-REAC™  Windows  services  still  presented  an  impassible  challenge. 

After  running  the  latter  option  for  two  weeks,  we  discovered  that  the  transfer  script  would  miss 
data  lines,  duplicate  lines,  or  be  delayed  by  other  processes  far  too  often,  to  be  useful.  This 
option  also  had  to  be  abandoned  and  we  instead,  went  back  to  the  old  manual  style  switch  and 
performed  a  manual  update  of  the  tower  data  at  least  once  a  week. 
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Figure  4.  A  schematic  and  photo  of  the  L-REAC™  System  Operational-Sensor  Module  hardware  mounted  on  a 
tripod,  which  was  located  on  a  subject  building  roof. 

2.2.3  Sensor  Module  Preparation 

Prior  to  the  sensor  and  tripod  installation  on  the  roof,  the  tripod  was  laid  out  to  identify  required 
heights,  fasteners,  grounding  cables,  cable  tie-downs,  data  cables,  tower  cross-arms,  and 
instrument  placing.  Each  sensor  was  individually  calibrated  against  a  standard  and  the  CR23X 
micrologger  software  was  tested  (see  figures  5  and  6). 


Figure  5.  RM  Young  5103  Wind  Monitor  and  Calibration  Equipment.  To  calibrate  wind 
speed,  the  Wind  Monitor  was  attached  to  a  motor,  which  was  calibrated  to  a 
predetermined  velocity.  Wind  direction  was  calibrated  using  the  fixed  compass 
reading  at  the  base  of  the  calibration  instrument. 
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Figure  6.  RM  Young  5103  Wind  Monitor  and  Calibration  Equipment.  The  wind 
monitor  recorded  the  calibrated  velocities  on  a  Campbell  CR23X 
micrologger  (in  the  white  box  under  the  table). 


2.2.4  Sensor  Module  Software 

As  previously  stated,  the  Operational-Sensor  Module  began  with  an  outward  appearance  of  the 
PoC.  However,  the  internal  design  maintained  the  Prototype  configuration.  That  is,  since 
security  protocols  on  the  networked  Operational  L-REAC™  computer  required  that  each  user 
have  a  different  login  and  password,  the  standard  LoggerNet  software  was  replaced  with  an 
Administrator  (ADM)  Version  4.0.  This  LoggerNet  ADM  version  allowed  the  acquisition 
programs  to  run  as  a  Windows  service,  instead  of  a  local  user  service.  In  other  words, 
LoggerNet  would  continue  to  run,  even  when  no  one  was  logged  on  to  the  machine. 

The  Campbell  Scientific,  LoggerNet  ADM  was  backward  compatible,  so  the  original  data 
acquisition  program  for  the  tripod  mounted  suite  could  be  downloaded  onto  a  new  Campbell 
CR23X  micrologger  (Campbell  Scientific,  Inc.,  2004).  The  micrologger  and  an  uninterruptable 
power  supply  (UPS)  were  co-located  in  a  Campbell  Scientific  ENC  16/18  Weather-Resistant 
Enclosure  at  the  base  of  the  tripod  on  which  all  the  Operational  L-REAC™  sensors  were 
mounted.  The  progranf's  function  was  to  control  the  data  collection  and  distribution. 
Specifically,  the  program  sampled  atmospheric  conditions  every  10  s,  then  output  1  min 
averages.  A  sample  of  the  micrologger  program  is  included  in  Volume  2  (Vaucher  et  ah,  2010). 

2.2.5  Sensor  Network  and  Functionally 

In  the  Operational-Sensor  Module,  all  sensors  were  hard-wired  into  the  CR23X  micrologger 
located  in  a  weather-resistant  enclosure  at  the  bottom  of  the  tripod.  This  data-logger  was  then 
wired  to  COM  port  1  on  the  Operational  L-REAC™  computer  via  an  RS-232  connection. 
Through  this  cabled  connection,  we  were  able  to  manipulate  the  program  in  the  CR23X 
micrologger  and  do  near  real-time  data  quality  control  screening  which  is  explained  in  more 
detail  in  section  2.3. 
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During  the  dual  system  data  access  task,  which  was  described  in  section  2.2.2,  we  experimentally 
switched  the  sensor  feed  back  to  an  alternate  computer  and  wrote  a  Bourne  shell  script  to  acquire 
the  sensor  data  from  the  alternate  computer  over  the  private  network.  The  data  source  provided 
one  minute  of  data  in  a  single  line.  The  operational  script  acquired  that  line,  ensured  that  line 
ended  with  a  carriage  return.  A  “new  line”  character  then  appended  that  line  to  the  current  day"s 
data  fde.  This  fde  was  supposed  to  be  equivalent  to  the  direct  data  feed  generated  by  the  original 
CR23X  LoggerNet  output  and  could  also  have  near  real-time  quality  control  screening 
perfonned  on  it.  While  most  of  the  time  this  worked,  as  we  mentioned  in  section  2.2.2,  this 
design  ran  into  trouble  because  of  network  delays  and  became  too  error  prone  to  continue 
pursuing.  Another  disadvantage  was  that  we  could  no  longer  control  the  micrologger  from  the 
Operational  L-REAC™  computer.  Instead,  all  programming  and  manipulation  of  the 
micrologger  could  only  be  done  through  the  alternate  computer. 

One  successful  resolution  to  the  quest  of  bringing  data  into  more  than  one  computer,  was  to 
connect  the  roof  data  into  a  four  position  switch  box  via  an  RS-232  connection.  The  alternate 
computer  was  connected  to  output  A,  the  Operational  L-REAC™  computer  was  connected  to 
output  B,  and  a  developmental  computer  was  connected  to  output  C.  The  down  side  with  this 
design  was  that  we  could  not  use  live  data  on  more  than  one  computer  at  once.  The  upside  was 
that  there  was  no  data  corruption  and  we  could  control  the  micrologger  from  each  of  the 
computers  when  they  are  selected  on  the  data  switch. 

2.3  Data  Quality  Control  Module 

The  data  QC  Module  was  created  in  response  to  a  need  for  a  quick  data  quality  review  on  the 
Operational  L-REAC™  System.  The  Module"s  concept  was  first  developed  and  tested  on  the  L- 
REAC™  System  PoC.  Once  successful,  the  software  was  converted  into  Production  Network 
code  for  the  Prototype  and  now  the  Operational  L-REAC™  System. 

The  QC  Module  design  begins  with  the  1  -min  average  micrologger  output  data  being  stored  in  a 
“live”  archive  file  at  the  beginning  of  each  minute.  The  archiver  script  “trims”  this  archive  file, 
storing  the  previous  day  (or  multi-day)  sensor  data  in  a  date-stamped  archive  file  and  removing 
these  data  from  the  live  archive  file.  The  live  archive  then  contains  only  current-day  data, 
starting  at  midnight  and  ending  at  the  last  archived  minute.  This  editing  operation  simplifies  the 
coding  of  a  Graphics  Layout  Engine  (GLE)  script  that  displayed  line  plots  of  sensed 
meteorological  parameters  as  functions  of  time  for  the  current  day.  This  script  was  originally 
designed  to  display  wind  speed  and  direction  plots  only,  but  the  simplicity  and  modularity  of  the 
GLE  scripting  syntax  allowed  an  expansion  of  the  display  to  include  all  of  the  sensed  parameter 
histories  on  a  single  screen  containing  six  plot  boxes  and  seven  parameter  (and  one  derived 
parameter)  curves. 
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The  position,  size,  scale,  and  content  of  each  plot  were  configured  by  GLE  commands  in  six 
serially  executed  plot  blocks.  The  plot  blocks  display  wind  direction,  wind  speed,  air 
temperatures  at  1-  and  6-m  above  the  roof  surface,  6-m  dewpoint  temperature,  air  temperature 
gradient  (derived  from  the  1-  and  6-m  temperatures),  RH  at  2-m  above  the  surface,  station 
barometric  pressure,  and  solar  irradiance  for  the  current  day.  The  latest  1-min  average  value  for 
each  parameter  is  also  captured  from  the  micrologger  file  and  displayed  in  a  message  string  at 
the  top  of  each  plot  box.  The  GLE  script  obtains  dewpoint  temperature  from  the  logged 
temperature  and  humidity  data  using  a  standard  conversion.  With  RH  given  in  percent  and 
ambient  temperature  T  given  in  degrees  Celsius  (C),  the  saturation  water  vapor  pressure  es  (in 
units  of  millibars)  may  be  expressed  as: 


,  .  .  n  (  17.67  T  \ 

6.112  exp  -  . 

r  \T +243.5/ 


The  RH  then  yields  the  ambient  water  vapor  pressure  e  (in  millibars): 


The  dewpoint  temperature  Td  (in  degrees  C)  may  then  be  expressed  as: 

T  _  243.5  in(e/6. 112) 

d  17.67-in(e/6.112)  ' 

Figure  7  displays  a  typical  screen  of  sensor  QC  data  plots  from  the  micrologger. 


Figure  7.  Example  of  GLE  plot  screen  for  quality  control  and  monitoring  of  Current  Sensor  Module  data. 

These  plots  have  utility  beyond  simply  verifying  nominal  sensor  suite  operation.  They  also 
allow  the  user  to  assess  trends  and  variability  in  the  environment  that  might  prove  to  be 
especially  significant  in  the  context  of  airborne  hazard  transport  and  diffusion.  For  example,  a 
relatively  stable  wind  direction  and  speed  would  probably  (though  not  always)  indicate  that 
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modeled  air  flow  fields  are  also  nearly  steady  in  the  neighborhood  of  the  sensor  suite.  Another 
example  might  be  the  indication  of  a  strong  negative  temperature  gradient  (or  lapse  rate)  that 
would  enhance  buoyant  plume  rise  during  advection.  Some  airborne  biohazards  are  sensitive  to 
cumulative  ultraviolet  exposure.  The  levels  for  such  exposure  can  be  readily  deduced  from  the 
solar  irradiance  plot  series,  which  might  be  especially  useful  under  conditions  of  partial  cloud 
cover. 

Another  application  for  the  QC  Module  is  to  examine  the  quality  and  consistency  of  modeled  air 
flow  solutions.  Highly  variable  winds  will  cause  modeled  wind  fields  to  change  abruptly  from 
one  display  cycle  to  the  next.  Extremely  light  winds  will  also  cause  plume  dispersion  model 
predictions  to  “bloom”  out  over  large  areas.  The  QC  data  time  series  provide  a  “sanity”  check 
on  such  model  results  either  in  near-real  time  or  as  part  of  a  post-event  analysis.  Indeed,  a 
version  of  the  QC  Module  screen  generator  has  been  created  to  examine  whole-day  archive  files 
for  post-event  investigation.  Figure  8  shows  an  example  of  the  archival  version  of  the  QC 
Module  display. 


Figure  8.  Example  of  GLE  plot  screen  for  daily  archival  data. 

The  archival  version  of  the  QC  display  screen  is  similar  to  the  near-real  time  version  with  the 
exception  that  the  “current”  value  headers  above  each  plot  are  replaced  by  diurnal  averages  (for 
wind  direction),  maxima  (for  wind  speed  and  solar  irradiance),  or  maxima/minima  (for  air 
temperature,  temperature  gradient,  RH,  and  station  atmospheric  pressure).  The  header 
information  content  is  easily  modified  to  accommodate  mission-specific  derived  parameters  such 
as  least-squares  fits  to  last-hour  data  (to  display  trends)  or  to  calculate  recent  variances  in 
parameter  values. 
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2.4  Model  Module 


The  Operational-Model  Module  was  designed  with  three  model  domains.  In  section  2.4.1,  these 
domains  are  described.  The  challenges  of  making  a  system  operational  and  a  future  vision  for 
the  Model  Module  are  presented  in  section  2.4.2. 

2.4.1  Operational  System  Model  Domains 

The  Operational-Model  Module  continued  to  support  the  functions  described  in  the  L-REAC™ 
System  Prototype.  One  of  the  distinguishing  features  of  the  Operational-Model  Module  was  the 
three  resolution  outputs.  Each  scale  was  designed  with  its  own  domain  and  reason  for  existence. 
The  5-m  grid  resolution  was  chosen  as  the  best  representation  of  the  building  scale  (figure  9). 
The  50-m  resolution  captured  winds  in  the  nearby  mountains,  as  well  as  the  entrances  to  the 
selected  cantonment  AOI  (figure  10).  The  100-m  resolution,  or  regional  scale,  was  chosen  as  a 
slightly  lower  resolution  for  getting  both  the  50-m  resolution  domain  and  designated  important 
areas  of  the  cantonment  (figure  1 1).  Although  the  100-  and  5-m  resolutions  are  the  only  ones 
actively  used,  all  three  domains  are  shown  in  figure  12. 


Figure  9.  Domain  of  the  5-m  Resolution  Model  (in  blue,  at  the  1622  pushpin). 
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Figure  10.  Domain  of  the  50-m  Resolution  Model  (in  blue). 
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Figure  11.  Domain  of  the  100-m  Resolution  Model  (small  blue  arrows  and  yellow  streamlines). 
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Figure  12.  Comparison  of  three  domains. 


2.4.2  Requirements  for  the  Model  Module  in  the  Operational  System 

The  requirements  for  an  Operational-Model  Module  were  extremely  difficult  to  know  a  priori. 
Therefore,  our  steps  toward  an  Operational-Model  Module  utilized  common  sense,  responding  to 
every  local  emergency  and  exercise  that  presented  itself  and  most  importantly,  responding  to  the 
customer  feedback.  Independent  of  customer  input,  the  initial  task  was  to  “bullet-proof’  the 
Module  code. 


2.4.2. 1  “Bullet-Proofing”  the  Module 

Common  sense  clearly  showed  that  no  data  quality  problems  affecting  the  reliability  or  accuracy 
of  the  Model  Module  should  be  allowed.  Since  the  L-REAC™  System  is  a  near  real-time 
response  unit,  ensuring  the  data  quality  in  an  equally  near  real-time  response  was  quite  a 
challenge.  The  data  QC  Module  attempts  to  ensure  the  best  quality  of  data  enters  the  Model 
Module.  Normally,  one  would  like  to  apply  a  climatological  limit  to  the  acceptable  weather  data, 
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but  surface  winds  have  such  a  climatological  range  that  this  was  not  effective.  In  addition,  winds 
may  be  very  strong  in  some  parts  of  an  AOI  and  not  in  other  parts  due  to  mountains,  fronts,  or 
local  forcing  factors.  And,  the  point  of  using  a  three  dimensional  wind  model  is  that  airflow  will 
have  different  wind  directions  over  an  operational  AOI,  due  to  buildings  and  terrain.  That  means 
that  an  eagle  perched  on  top  of  a  wind  sensor  (actual  occurrence,  figure  13)  will  affect  the  wind 
direction  reported  at  that  sensor  but  unfortunately,  that  effect  will  not  be  captured  by  the  efforts 
to  “bullet-proof’  the  model  input.  What  can  be  captured  are  missing  winds  in  a  mesonet  surface 
observation  and  a  data  report  that  is  more  than  3 1  min  old.  Both  of  these  “bullet-proofing” 
features  were  integrated  into  the  Operational-Model  Module. 

The  loss  of  all  data  except  the  dedicated  input  causes  model  output  degradation  but  not  complete 
failure.  This  scenario  was  experienced  by  the  Operational  L-REAC™  System  numerous  times,  as 
network  connectivity  to  the  mesonet  resources  was  not  always  reliable.  Fortunately,  the  only 
Operational-Sensor  Module  failure  recorded  occurred  after  an  extended  power  outage  during  an 
un-manned  time  period. 


Figure  13.  Eagle  Perched  on  Wind  Vane  Photo  by  Pam  Birley  using  the 

racerocks.com  remote  controlled  camera  5  at  Race  Rocks  Ecological 
Reserve.  Courtesy  of  Lester  B.  Pearson  College,  Victoria,  BC.  Canada 
(Birley,  2011). 


2.4.2.2  Refinements  Added 

Thanks  to  customer  feedback  on  L-REAC™  during  a  local  wildfire  emergency,  refinements  were 
added  to  enhance  the  usefulness  of  the  model  module.  These  refinements  included  a  listing  of 
the  available  mesonet  observations  with  the  model  run  time,  the  RH  and  the  winds.  Also,  output 
was  made  available  to  the  display  module  at  two  levels  (2.5  and  10  m;  human  height  level  and 
standard  observation  level,  respectively).  Using  firefighter  comments,  winds  were  considered 
important  at  the  level  of  the  fire  fighters,  the  underbrush,  the  treetops  and  heights  significant  to 
aerial  fire  suppression  efforts,  which  include  both  fire  suppressant  drops  and  tank  refill.  In 
addition,  the  RH  was  defined  as  crucial  for  fire  motion  forecasts. 
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2.4.2. 3  Future  Model  Module  Refinements 

There  are  five  highly  desired  refinements  identified  for  a  future  Operational-Model  Module: 

(1)  the  use  of  lower  resolution  model  output  to  act  as  the  first  guess  analysis  of  the  observations, 

(2)  a  simple  setup  procedure  for  new  locations,  (3)  re-locatable  higher  resolution  windows  within 
the  lower  resolution  output,  (4)  two  forms  of  model  output  to  initialize  the  plume  model,  and 

(5)  the  use  of  a  prediction  model  output  to  determine  the  upper  level  winds.  There  are  uses  and 
hindrances  associated  with  each  effort. 

Using  the  lower  resolution  (larger  domain)  model  solutions  to  initialize  the  higher  resolution 
(smaller  domain)  model  runs,  insures  that  terrain  outside  those  smaller  domains  and  away  from 
available  observations  would  be  taken  into  consideration.  Executing  this  task  requires  reading 
the  lower  resolution  output,  taking  the  proper  part  of  the  larger  domain  and  interpolating  it  to  the 
higher  resolution.  The  most  efficient  way  of  implementing  the  task  would  be  to  take  the  results 
of  the  lower  resolution  data  at  the  same  height  of  the  surface  observations,  interpolate  the  entire 
field  to  the  proper  resolution,  and  make  a  separate  output  file.  Since  the  larger  domain  takes 
longer  to  run,  this  process  would  not  be  run  as  often  as  the  higher  resolution  model,  and  the 
proposed  output  file  might  be  quite  old  when  used  as  the  input  for  the  smaller  domain  run. 

To  re-locate  the  Model  Module  to  a  new  location  will  require  terrain  and  building  information. 
Although  there  are  several  sources  for  terrain  information,  most  of  the  sources  are  difficult  to 
convert  into  the  form  required  for  the  model.  Also,  most  terrain  sources  are  not  suitable  for  the 
resolution  required  by  the  model.  The  most  promising  terrain  source  is  the  National  Elevation 
Dataset  (NED)  data  set,  which  covers  the  continental  United  States  at  90-  and  30-m  resolutions, 
as  well  as,  a  small  part  of  the  United  States  at  about  10-m  resolution.  For  worldwide  terrain 
coverage,  there  is  the  Department  of  Defense  (DoD)  product  called  Digital  Terrain  Elevation 
Data  (DTED),  which  is  readily  available  to  the  DoD  at  30-m  resolution.  The  setup  for  a  new 
location  will  require  a  dedicated  period  for  gathering  terrain  and  building  data.  This  task  needs 
to  be  done  before  responding  to  any  emergencies  in  a  new  area.  A  first  responder  will  want  to 
see  high  resolution  output  in  the  vicinity  of  a  hazardous  incident. 

Although  the  current  high  resolution  output  is  in  the  region  of  the  most  probable  AOI,  this 
configuration  will  not  always  be  applicable.  Therefore,  a  re-locatable  higher  resolution  window 
may  be  more  useful  to  the  first  responders  and  incident  managers.  To  make  this  possible,  higher 
resolution  terrain  and  building  footprints  are  required  for  the  entire  domain  of  the  lower 
resolution  run.  However,  there  are  three  challenges:  First,  while  getting  terrain  at  high 
resolutions  in  the  cantonment  AOI  is  relatively  easy  because  it  is  flat  and  open  for  interpolation- 
this  is  not  true  for  the  rest  of  the  larger  domain.  Second,  selecting  and  getting  the  flow  for  a 
location  at  higher  resolution  will  often  be  required  in  the  midst  of  an  emergency  situation.  Thus 
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there  would  be  no  time  to  get  the  terrain  and  building  information  from  original  sources.  Third, 
the  method  of  communicating  the  location  of  the  re-locatable  window  is  not  obvious.  In  fact,  the 
location  used  to  determine  the  high  resolution  window  would  also  have  to  be  used  to  determine 
the  new  location  of  the  plume  window  and  the  location  of  the  streamline  overlay  image,  leading 
to  additional  complexities  in  the  display  of  the  output. 


The  constraints  of  the  two  previous  refinements  requires  a  technique  that  provides  the  low  and 
high  resolution  terrain  at  the  Model  setup  time,  as  well  as,  the  re-locatable  windows  using  the 
pre-computed  high  resolution  terrain  selected  for  only  the  window  location  (no  interpolation 
required).  Using  red  for  not  started,  blue  for  under  construction  and  white  for  complete,  this 
technique  is  proposed  in  figure  14. 


Figure  14.  Initial  versus  re-locatable  high  resolution  window  setup. 

As  currently  operated,  the  L-REAC™  plume  model  is  based  on  a  single  wind  location  from  the 
trusted,  dedicated  Sensor  Module.  However,  model  evaluations  have  shown  that  the  wind  used 
for  the  plume  is  not  always  representative  of  the  entire  area.  This  problem  would  certainly 
become  more  distinct  when  the  higher  resolution  model  is  re-locatable  throughout  the  entire  low 
resolution  domain.  There  are  three  potential  methods  for  solving  this  problem.  First,  one  could 
choose  the  nearest  observed  wind  to  the  plume  release  point.  Second,  model  output  (from  either 
the  model  results  or  from  the  model  initialization  field)  could  be  used.  Third,  a  combination  of 
the  two  choices  could  also  be  used,  such  as  using  the  nearest  observation  within  100  m  and  if  this 
option  is  not  available,  then  using  a  model  wind.  Each  of  these  solutions  has  the  additional 
problem  that  the  winds  are  not  the  only  parameters  used  to  initialize  the  plume  model.  Some 
method  must  be  found  to  provide  the  other  required  thennodynamic  parameters. 

Finally,  there  is  a  need  to  anchor  the  upper  level  winds,  even  in  boundary  layer  volumes. 
Unfortunately,  standard  upper  air  wind  observations  are  taken  too  seldom  to  be  useful  for  this 
time-constrained  application.  A  microwave  wind  profiler  might  be  useful,  but  represents  a 
volume  measurement  that  may  or  may  not  be  applicable.  In  the  absences  of  measured  upper 
level  winds,  a  mesoscale  weather  prediction  model  (such  as  the  community  Weather  Research 
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and  Forecasting  [WRF]  model)  might  be  able  to  fill  the  void.  There  are  two  ways  such  a  model 
could  be  used.  First,  the  output  from  the  model  at  10-m  AGL  could  be  interpolated  horizontally 
and  in  time,  to  serve  as  the  first  guess  for  the  regional  model  initialization.  Second,  the  winds 
above  a  level  representing  the  boundary  layer  could  also  be  interpolated  horizontally  and  in  the 
time  dimension,  in  order  to  form  the  upper  air  winds.  These  upper  air  wind  speeds  and 
directions  could  be  blended  on  top  of  the  initialization  formed  from  the  surface  observations. 

2.5  EUD  Module 

The  Operational  EUD  Module  design  continued  the  successful  dual  configuration  of  the 
Prototype:  (1)  a  EUD  Module-Plume  Model,  which  for  demonstration  purposes  was  the 
NOAA/EPA  ALOHA  dispersion  model;  and  (2)  a  EUD  Module-Display,  which  consisted  of  a 
continuous  stream  of  the  latest  available  outputs  from  both  the  Wind  and  Plume  models. 

As  with  the  Prototype,  the  EUD-Plume  Model  was  initialized  by  the  user  only  when  an  incident 
occurred,  then  run  automatically  by  the  system,  employing  the  latest  sensor  data  updates.  The 
EUD  Module-Display  included  two  screens:  (1)  a  single  plot  which  showed  both  wind  field  and 
plume  footprints  over  a  Google  Earth  satellite  image,  and  (2)  a  two  plot  slide  consisting  of  the 
building  scale  wind  field  and  plume  footprint.  When  no  plume  was  present,  a  default  text 
indicating  “no  known  hazard”  replaced  the  plume  entry. 

2.5.1  Operational  EUD  Module-Plume  Model 

The  Operational  EUD  Module-Plume  Model  remained  the  EPA/NOAA  ALOHA  dispersion 
model  for  demonstration  purposes.  The  Quick  Urban  and  Industrial  Complex  (QUIC)  model 
created  by  the  Los  Alamos  National  Laboratory  was  also  installed  on  the  operational  system.  A 
feasibility  study  showed  that  this  alternate  plume  model  was  also  able  to  function  as  an 
application  model  and  included  the  timeliness  for  processing,  required  by  the  original 
L-REAC™  System  concept.  The  Hazard  Prediction  and  Assessment  Capability  (HP AC)  and 
“X-PAC”  (a  modification  of  HP  AC)  were  two  other  application  models  investigated  for  potential 
inclusion  in  the  L-REAC™  demonstration  design.  Based  on  end  user  interest  levels,  no 
feasibility  studies  were  pursued. 

2.5.2  Operational  EUD  Module-Displays 

The  operational  system  underwent  a  detailed  evaluation  by  professional  first  responder  end 
users.  While  the  specific  findings  of  the  results  will  be  published  in  a  separate  document,  some 
of  their  recommendations  were  already  implemented  in  the  Operational  L-REAC™  System. 

Based  on  the  end  user  feedback,  the  Two-Plot  EUD  Display  (figure  15)  required  no  changes. 

The  users  said  they  could  easily  discern  orientation,  the  general  wind  field  and  the  plume 
gradient  information. 
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3  AEGL-J:  Health  effects  life-threatening  or  death. 


Figure  15.  Example  of  the  Operational  L-REAC™  System  EUD  Module-Two  plot  output. 

The  “1-Plot”  EUD  Display  (figure  16)  was  redesigned  to  include  several  additional  pieces  of 
information.  As  explained  in  the  Model  Module,  the  fire  department  expressed  a  need  to  have 
numerical  winds  in  “miles  per  hour”  and  RH  in  “percentages.”  The  process  to  create  this  text 
resource  required  the  Model  Module  to  save  the  meteorological  values  ingested  from  the 
dedicated  L-REAC™  sensor  module  and  the  mesonet  resource.  Using  a  VBScript,  these  values 
were  tabulated  and  saved  as  an  image.  After  re-designing  the  HTML  1-plot  template,  the  data- 
list  image  was  inserted  onto  the  EUD-Display  and  automatically  updated  with  each  Model 
Module  run. 

Concurrent  with  the  data-list  request  was  a  preference  for  a  larger  time  stamp.  Therefore,  the 
local  date  and  time  information  were  extracted  from  the  dedicated  sensor  module  resource  and 
inserted  into  the  tabulated  data  listing  described  above.  By  using  larger  font  and  a  bright  red 
color  to  distinguish  this  text  from  the  data-list,  the  end  users  “quick  read”  request  was  satisfied. 
The  conversion  of  the  tabulated  data  into  an  image  meant  that  the  time  stamp  would 
automatically  be  archived  for  future  reference.  We  elected  to  keep  the  time  stamp  in  local  time. 
This  decision  was  based  on  the  fact  that  the  system  is  designed  for  a  “Local”  rapid  evaluation  of 
atmospheric  conditions.  The  probability  that  the  AOI  might  extend  to  another  time  zone  is 
limited  for  now. 


23 


Figure  16.  Example  of  the  Operational  L-REAC™  System  EUD  Module-One  plot  output. 

2.5.3  Automated  EUD  Updates 

The  Operational  automatic  updates  of  the  latest  Wind  and  Plume  (if  applicable)  Model  outputs 
used  specialized  JavaScript  code  that  was  integrated  into  an  HTML  program,  and  a  winBatch 
executable. 

With  the  expansion  from  building  and  cantonment  scale  AOI  to  a  regional-scale  AOI,  the  EUD 
Module  required  additional  flexibility  in  the  automated  functions  updating  the  output.  The  most 
significant  change  was  increasing  the  time  needed  to  save  the  results  from  a  100-m  resolution 
run  versus  a  5-m  resolution  run,  without  compromising  system  efficiency. 

The  end  user  evaluations  indicated  impatience  toward  waiting  the  8-10  min  for  a  100-m 
resolution  model  run.  Consequently,  an  “instant  save”  button  was  created.  This  automated  save 
button  would  allow  an  operator  to  zoom  in  or  out  of  an  AOI,  and  instantly  save  the  new 
perspective  for  the  waiting  end  user.  The  time  needed  to  go  through  the  entire  save  routine  was 
between  20-28  seconds  (s).  For  this  smaller  interval,  the  end  users  were  willing  to  wait. 

2.5.4  Accessing  the  Operational  EUD  Module  Display 

The  L-REAC™  PoC  output  display  used  a  Sony  Vega  Plasma  high  definition  television  (HDTV) 
screen  located  in  the  lobby  of  an  office  building  and  a  strategically-placed  networked  computer 
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with  a  digital  screen  projector.  When  non-local  emergency  professionals  requested  near  real¬ 
time  access  to  the  L-REAC™  System  PoC  output,  a  procedure  to  manually  transfer  approved 
output  onto  a  restricted-access  Web  site  was  developed. 

The  Prototype  simplified  the  complexity  of  the  remote  access  methods  by  automatically  sending 
the  results  through  an  approved  network  linked  to  an  end-user  accessible  location  (such  as  a  SIP 
location  or  an  Emergency  Operations  Center  [EOC]).  With  a  double  click  of  the  mouse,  the  end 

TM  .  TM 

user  initiated  resident  L-REAC  software,  to  view  the  L-REAC  output  with  automated 
updates. 

The  Operational  L-REAC™  System  method  for  communicating  the  EUD  Module-Display 
continued  the  use  of  an  approved  network  link,  using  an  access-restricted  directory  on  a  DMZ 
network.  Confined  by  security  requirements,  the  automated  L-REAC™  sent  the  final  outputs  to 
this  DMZ  directory,  from  which  the  approved  end  users  could  independently  access  the  latest 
information.  The  remote  site  users  would  get  automated  updates  prompted  by  the  L-REAC™ 
System  software  resident  on  the  DMZ  directory  and  activated  on  the  end  user"s  computer.  Flat 
files  of  the  wind  and  plume  plots  were  included  in  this  directory  to  allow  end  users  to  e-mail 
needed  information  to  hand-held  blackberry  devices  in  the  field.  While  viewing  the  results  on 
these  hand-held  devices  was  challenging,  the  concept  was  seen  as  worth  pursuing.  At  the  time  of 
this  writing,  the  authorized  users  of  the  near  real-time  Operational  L-REAC™  System  output 
included  the  WSMR  Installation  Operations  Center  (IOC),  the  WSMR  EOC,  the  WSMR  Fire 
Department,  approved  ARL  workforce  from  three  different  directorates,  and  the  ARL  SIP  room. 

In  the  future,  we  want  to  bring  the  L-REAC™  EUD  Module-Display  output  to  a  true  server, 
where  the  only  limitation  is  on  what  technology  the  user  can  read/view  an  Intemet/HTML  file. 

2.6  Archive  Module 

The  Operational  L-REAC™  System-Archive  Module  used  the  Single  Editing  Pass  (SEP) 
configuration  that  was  developed  for  the  Prototype  L-REAC™  System  and  described  in  Volume 
2  of  this  technical  report  series  (Vaucher  et  al,  2010).  A  condensed  description  of  the  layout  and 
operation  of  that  module  were  adapted  from  the  Volume  2  report  here  for  the  reader's 
convenience. 

2.6.1  Workstation  (SEP)  Version  of  the  Archive  Module 

Automated  operation  of  the  Operational  L-REAC™  System  data  archiving  VBScript  in  the  ARL 
networking  environment  requires  installation  of  a  proprietary  Windows  process-as-a-service 
utility  known  as  Fire  Daemon.  Fire  Daemon  allows  user  applications  to  be  run  as  Windows 
services,  which  can  persist  between  user  logins  and  can  execute  user  applications  on  a  periodic 
schedule.  However,  the  archiving  script  was  designed  to  rely  on  system  timing  as  little  as 
possible. 
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The  data  archiving  script  employs  a  SEP  concept,  where  the  Julian  Day  (JD)  (day  number  for  the 
given  year,  ranging  from  1  to  365  or  366)  field  of  the  logger  data  file  is  used  to  automatically 
edit  the  logger  data  file  into  individual-day  archive  files.  Before  performing  its  archive 
generation  operation,  the  script  does  make  two  references  to  the  system  clock  (see  figure  17). 


Figure  17.  SEP  archiving  VBScript  logic  flow  diagram  overview. 

The  first  reference  is  to  the  current  time,  expressed  as  seconds  past  midnight  for  the  current  day. 
The  number  of  seconds  past  the  beginning  of  the  current  minute  for  the  current  time  is  then 
determined  through  a  modulo  60  operation.  The  final  step  of  the  archive  creation  cycle  (see 
figure  1 8)  is  to  overwrite  the  data  logger  file  with  a  truncated  version  of  itself,  which  only 
contains  today"s  data.  The  logger  writes  to  the  log  file  at  the  beginning  of  each  minute,  so  the 
archiver  script  delays  its  overwriting  operation  when  it  is  executed  within  ±15  s  of  that  time 
(figure  17).  The  second  reference  to  the  system  clock  is  used  to  get  the  current  year;  a  modulo  4 
operation  then  determines  whether  or  not  the  current  year  is  a  leap  year  and  assigns  the 
appropriate  end-of-month  JD  values  to  a  monthly  array. 
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Figure  18.  SEP  VBScript  archive  generation  and  update  cycle  (detail  view  from  figure  17). 

This  array,  combined  with  line-by-line  reads  from  a  scratch  file  copy  of  the  data  log  file,  is  used 
to  decode  the  JD  of  each  data  record,  encode  an  appropriate  archive  file  name,  write  the  data 
record  to  that  file,  and  then  close  the  file  after  all  records  having  that  same  JD  tag  have  been 
processed  (figure  18). 

This  SEP  version  of  the  script  may  be  run  interactively  (by  double-clicking  the  file  icon)  or  as  a 
Fire  Daemon-administered  service.  The  script  was  tested  both  ways  and  works  as  designed. 
Currently,  the  Fire  Daemon  service  runs  this  script  at  0500  local  time  each  day. 

2.7  Scripts  and  Automation 

L-REAC™  System  Start  Up  Scripts :  The  operational  system  uses  a  two  step  “start  up”  process. 

In  step  one,  the  user  double  clicks  on  a  script  that  initiated  the  data  conversion  routine  for  the 
plume  model.  In  step  two,  the  user  double  clicks  on  a  second  script  that  initiated  both  the  wind 
and  plume  models.  When  no  plume  model  is  required,  the  foundational  software  still  runs  in  the 
background,  waiting  for  the  chemical  data  to  be  defined.  For  the  “no  plume”  status,  the  end  user 
is  informed  on  the  EUD  Module-Display  that  “there  is  no  known  airborne  threat.” 
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End  User  Access:  The  authorized  end  user  gains  access  to  the  Operational  output  through 
HTML  display  programs  that  remained  resident  on  a  designated  DMZ  directory.  These 
programs  are  located  both  locally  on  the  operational  system,  and  at  an  accessible  remote  site 
location.  A  special,  single  script  is  created  at  the  designated  remote  site,  so  the  user  can  double¬ 
click  on  the  script  icon,  and  the  L-REAC™  EUD  Module-Display  HTML  programs  self-initiate, 
and  automatically  update. 

TM  .  TM 

L-REAC  System  Shutdown  Script:  When  the  Operational  L-REAC  System  is  no  longer 
needed,  the  operator  of  the  L-REAC™  System  utilizes  a  “shutdown”  script.  This  single  script 
tenninates  all  operational  L-REAC™  System  software,  except  the  LoggerNet,  the  mesonet  data 
ingest,  and  the  daily  Archive  Module.  These  data  ingest  and  storage  functions  remain  as 
background  jobs,  in  preparation  for  future  operational  L-REAC™  System  usage. 


3.  Discussion 


In  this  section,  we  flag  attributes  of  the  current  operational  system  that  have  not  yet  reached  their 
full  maturity,  as  well  as  a  future  vision  for  the  L-REAC™  System. 

The  L-REAC™  System-Sensor  Module  design  calls  for  a  dedicated  sensor  suite  as  well  as  a 
mobile  sensor  suite.  The  dedicated  sensor  has  already  been  demonstrated  and  proven.  The 
mobile  sensor  has  yet  to  be  demonstrated.  The  key  attributes  of  this  mobile  suite  would  be  the 
ability  to  assemble  such  a  unit  within  minutes,  while  being  fully  attired  in  a  professional 
Hazardous  Materials  (HAZMAT)  suit.  The  purpose  of  the  mobile  sensor  suite  would  be  to 
provide  L-REAC™  with  in  situ  measurements.  These  data  points  would  especially  strengthen  the 
applicability  of  the  plume  model  output.  These  data  sampled  would  not  be  limited  to  just 
meteorological  parameters.  As  with  the  dedicated  sensor  suite,  airborne  hazard  sniffers  have 
also  been  envisioned  for  the  Sensor  Module.  The  L-REAC™  System  design  calls  for  these 
features;  however,  until  funding  becomes  available,  they  remain  on  paper  only. 

To  bring  additional  data  into  the  L-REAC™  System  requires  a  flexible  ingest  code.  One  vision 
for  the  Sensor  Model  was  to  create  a  radio  button  where  multiple,  known  data  formats  could  be 
ingested.  Along  this  same  thought,  model  data  ingest  requirements  could  also  be  designed 
around  a  radio  button  option  capable  of  reformatting  data  files. 

The  models  chosen  for  the  L-REAC™  System  demonstration  unit  were  not  the  only  models  the 
system  was  designed  to  accommodate.  In  section  2,  a  feasibility  study  was  conducted  to 
detennine  the  practical  requirements  for  inserting  alternate  and  additional  (second  tier)  models. 
With  this  feature,  if  another  wind  field  or  plume  model  was  required  by  a  customer  site,  the 
L-REAC™  System  could  accommodate  the  requirement.  The  design  would  insert  the  alternate 
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model  as  new  primary  wind  or  plume  models;  or  these  models  would  be  built  as  slower  second 
tier  models  to  run  on  another  computer  processor  in  the  background.  The  only  requirement  that 
the  L-REAC™  designers  would  put  on  the  new  models,  is  that  models  designated  as  “primary” 
would  be  able  to  provide  timely  and  relevant  data  to  the  end  users. 

The  Model  Module  has  numerous  areas  in  which  to  expand.  Regarding  local  airflows,  some 
additional  features  that  could  be  added  to  the  current  model  would  include  slope  flow,  shadows, 
surface  radiation  balance  and  upper  level  winds.  Another  suggestion  for  the  Model  Module  was 
to  have  all  sensors  report  at  the  same  frequency.  This  attribute  may  not  be  practical;  however,  it 
would  simplify  the  objective  analysis. 

Communicating  with  the  “outside”  world  using  a  controlled  access  network  was  one  of  the 
greatest  challenges  to  the  L-REAC™  System  demonstration  unit  design.  After  exploring  many 
options,  the  designers  will  be  working  with  the  ARL  and  WSMR  webmasters  to  get  L-REAC™ 
output  published  onto  a  security-acceptable  website.  This  task  may  seem  trivial,  but  working 
within  the  guidelines  of  DoD  Cyber  Security,  it  is  very  challenging  at  best.  The  current  design 
calls  for  an  L-REAC™  button  on  the  front  page  of  the  DoD  Web  site.  When  a  user  clicks  on  this 
L-REAC™  icon,  his/her  access  is  verified  as  acceptable  and  allowed  to  enter  the  read  only  area. 
If  an  individual  is  certified  to  operate  the  L-REAC™  System,  he/she  would  be  able  to  login  and 
start  the  plume  model,  or  adjust  the  view  of  the  output  maps,  to  meet  the  immediate  need  of  an 
incident. 

The  use  of  hand-held  displays  is  a  definite  vision  for  this  system.  This  option  was  proven 
feasible  during  the  Prototype  development.  Only  the  lack  of  time  and  resources  prevented  the 
integration  of  this  feature  into  the  operational  system. 


4.  System  Evaluation  by  Professional  First  Response  End  Users 


The  Operational  L-REAC™  System  was  introduced  to  the  “real  world”  operational  environment 
through  an  unexpected  invitation  to  assist  with  a  local  fire  actively  threatening  the  local  and 
work  communities.  The  2011  April  event  was  called  “the  Abrams  Fire.”  This  three-day  event 
gave  the  system  access  to  practical  feedback.  The  L-REAC™  System  had  already  been  through 
numerous  site  exercises,  which  allowed  this  “real  world”  experience  to  be  positive  for  both  the 
developers  and  the  professional  first  responders. 

As  a  consequence  of  the  Abrams  Fire,  we  were  asked  to  train  the  local  IOC  and  Fire  Department 
personnel  on  the  L-REAC™  System.  Eleven  training  sessions  were  conducted,  producing 
potential  L-REAC™  System  operators  from  the  IOC,  the  Fire  Department,  the  EOC  and  ARL 
(not  including  the  developers). 
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In  the  course  of  the  training  sessions,  we  included  two  multiple-page  evaluation  questionnaires 
From  these  questionnaires,  we  learned  that  the  output  was  user-friendly,  that  the  most  popular 
choices  regarding  recommendations  for  L-REAC™  users  were  the  IOC,  EOC,  police,  and 
incident  commanders;  and,  that  the  majority  of  evaluators  thought  all  elements  included  in  the 
EUD  output  were  “most  important”  to  their  decision  making  responsibilities.  Additional 
evaluation  material  will  be  published  separately. 


5.  Summary  and  Final  Comments 


This  report  is  the  third  of  three  reports  documenting  the  L-REAC™  System  development,  which 
was  funded  by  ARL  mission  resources.  There  are  nine  technology  readiness  levels  required  to 
bring  this  system  from  concept  to  maturity.  With  this  report,  we  have  completed  five  levels. 

The  feedback  from  professional  first  responders  has  been  most  encouraging.  It  is  the  authors" 
hope  that  the  opportunity  to  transfer  this  technology  into  an  Anny  resource  will  continue,  and  as 
we  saw  in  the  “real  world”  event,  that  this  decision  aid  will  continue  to  make  a  difference  in  the 
mission  of  saving  civilian  and  Soldier  lives. 
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List  of  Symbols,  Abbreviations,  and  Acronyms 


3DWF 

Three-Dimensional  Wind  Field 

ADM 

Administrator 

AGL 

above  ground  level 

ALOHA 

Areal  Locations  of  Hazardous  Atmospheres 

AOI 

area(s)  of  interest 

ARL 

U.  S.  Anny  Research  Laboratory 

C 

Celsius 

DMZ 

Demilitarized  Zone 

DoD 

Department  of  Defense 

DTED 

Digital  Terrain  Elevation  Data 

EOC 

Emergency  Operations  Center 

EPA 

Environmental  Protection  Agency 

EUD 

End  User  Display 

FY1 1 

fiscal  year  2011 

GLE 

Graphics  Layout  Engine 

GrADS 

grid  analysis  and  display  system 

HAZMAT 

Hazardous  Materials 

HDTV 

high  definition  television 

HP  AC 

Hazard  Prediction  and  Assessment  Capability 

HTML 

HyperText  Markup  Language 

IOC 

Installation  Operations  Center 

JD 

Julian  Day 

kml 

keyhole  markup  language 

L-REAC™ 

Local-Rapid  Evaluation  of  Atmospheric  Conditions  System 
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mph 

NED 

NO  A  A 

OS 

PoC 

QC 

QUIC 

RH 

s 

SAMS 

SEP 

SIP 

UPS 

VBScript 

WO  3  US 

W05US 

W07US 

WRF 

WSMR 

XPAC 


miles  per  hour 
National  Elevation  Dataset 

National  Oceanic  and  Atmospheric  Administration 
operating  system 
Proof  of  Concept 
Quality  Control 

Quick  Urban  and  Industrial  Complex 

relative  humidity 

second 

Surface  Automated  Meteorological  System 

Single  Editing  Pass 

shelter-in-place 

uninterruptable  power  supply 

Visual  Basic  Script 

White  Sands  Missile  Range  2003  Urban  Study 
White  Sands  Missile  Range  2005  Urban  Study 
White  Sands  Missile  Range  2007  Urban  Study 
Weather  Research  and  Forecasting 
White  Sands  Missile  Range 

A  modified  version  of  Hazard  Prediction  and  Assessment  Capability  model 
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No.  of 

Copies  Organization 

1  (PDF)  ADMNSTR 

DEFNS  TECHL  INFO  CTR 
DTIC  OCP 

8725  JOHN  J  KINGMAN  RD  STE  0944 
FT  BEL  VOIR  VA  22060-6218 

3  HCs  US  ARMY  RSRCH  LAB 

ATTN  RDRL  CIO  MT 
TECHL  PUB 
ATTN  RDRL  CIO  LL 
TECHL  LIB 

ATTN  IMNE  ALC  HRR 
MAIL  &  RECORDS  MGMT 
2800  POWDER  MILL  ROAD 
ADELPHI  MD  20783-1 197 

6  CDs  US  ARMY  RSRCH  LAB 

10  HCs  G  VAUCHER 

ATTN  RDRL  CIE  D 
BLD  1622 
WSMR  NM  88002 

1  CD  US  ARMY  RSRCH  LAB 

R  BRICE 

ATTN  RDRL  CIE  D 
BLDG  1622 
WSMR  NM  88002 

1  CD  US  ARMY  RSRCH  LAB 

S  LUCES 
ATT  RDRL  CIE  D 
BLDG  1622 
WSMR  NM  88002 

1  CD  US  ARMY  RSRCH  LAB 

S  OBRIEN 
ATT  RDRL  CIE  D 
BLDG  1622 
WSMR  NM  88002 

Total  23  (1  PDF,  13  HCs,  9  CDs) 
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